vscode/core/src/utilities/ModifiedFiles/handleModifiedFile.ts (1)

184-186: Replace console.* with structured logger

Use state.logger.child({ component: "handleModifiedFileMessage" }) for uniform logs and levels.

@@
-          console.error(
-            `ModifiedFile interaction timeout for ${filePath} (${msg.id}) - auto-resolving to prevent stuck state`,
-          );
+          const logger = state.logger.child({ component: "handleModifiedFileMessage" });
+          logger.warn("ModifiedFile interaction timeout - auto-resolving", { filePath, messageId: msg.id });
@@
-            console.error(`Error in ModifiedFile resolver for messageId: ${msg.id}:`, error);
+            const logger = state.logger.child({ component: "handleModifiedFileMessage" });
+            logger.error("Error in ModifiedFile resolver", { messageId: msg.id, error });
@@
-    console.error(`Error in handleModifiedFileMessage for ${filePath}:`, err);
+    state.logger.error("Error in handleModifiedFileMessage", { filePath, error: err });
@@
-      console.error(`Error during cleanup for ${filePath}:`, cleanupError);
+      state.logger.error("Error during cleanup", { filePath, error: cleanupError });

Additionally, initialize the child logger once near the top of the function to avoid re-creating it.

Also applies to: 221-221, 235-235, 252-252

webview-ui/src/components/ResolutionsPage/ResolutionsPage.tsx (1)

203-206: Nit: remove unused dependency to avoid re-renders

isFetchingSolution isn’t used inside renderChatMessages.

-  }, [chatMessages, isFetchingSolution, isAnalyzing, triggerScrollOnUserAction]);
+  }, [chatMessages, isAnalyzing, triggerScrollOnUserAction]);

vscode/core/src/commands.ts (1)

195-205: Also reset isProcessingQueuedMessages in the manual reset command

Prevents stuck “Processing…” UI after failures.

     state.mutateData((draft) => {
       draft.isFetchingSolution = false;
       if (draft.solutionState === "started") {
         draft.solutionState = "failedOnSending";
       }
       draft.isWaitingForUserInteraction = false;
+      draft.isProcessingQueuedMessages = false;
     });

vscode/core/src/utilities/ModifiedFiles/queueManager.ts (4)

23-28: Initialize logger before starting background timer.

Minor race: setInterval is scheduled before this.logger is assigned. It’s unlikely to tick first, but invert the order for safety.

-    // Start background processor that runs continuously
-    this.startBackgroundProcessor();
-    this.logger = state.logger.child({
+    this.logger = state.logger.child({
       component: "MessageQueueManager",
     });
+    // Start background processor that runs continuously
+    this.startBackgroundProcessor();

---

35-37: Reduce log noise; use debug for per-message logs.

Per-message info logs will flood logs at scale. Keep start/end at info; switch enqueue/each-message to debug.

-    this.logger.debug(
+    this.logger.debug(
       `Message enqueued: ${message.type}, id: ${message.id}, queue length: ${this.messageQueue.length}`,
     );
@@
-    this.logger.info(`Starting queue processing, ${this.messageQueue.length} messages in queue`);
+    this.logger.info(`Starting queue processing, ${this.messageQueue.length} messages in queue`);
@@
-        this.logger.info(
+        this.logger.debug(
           `Processing message: ${msg.type}, id: ${msg.id}, remaining in queue: ${this.messageQueue.length}`,
         );
@@
-      this.logger.info(`Queue processing complete, ${this.messageQueue.length} messages remaining`);
+      this.logger.info(`Queue processing complete, ${this.messageQueue.length} messages remaining`);

Also applies to: 107-107, 115-117, 145-145

---

119-131: Avoid dynamic import inside the processing loop.

Import once outside the loop to reduce overhead (module cache helps, but hoisting is cleaner).

   try {
-      // Process messages one at a time from the front of the queue
+      // Import once
+      const { processMessageByType } = await import("./processMessage");
+      // Process messages one at a time from the front of the queue
       while (this.messageQueue.length > 0 && !this.state.data.isWaitingForUserInteraction) {
@@
-          // Call the core processing logic directly
-          const { processMessageByType } = await import("./processMessage");
           await processMessageByType(

---

189-204: Optionally set UI processing flag on resume after interaction.

When resuming with a non-empty queue, consider surfacing progress to the UI.

   state.mutateData((draft) => {
     draft.isWaitingForUserInteraction = false;
+    if (queueManager.getQueueLength() > 0) {
+      draft.isProcessingQueuedMessages = true;
+    }
   });

webview-ui/src/context/ExtensionStateContext.tsx (2)

48-50: Prefer nullish coalescing to preserve explicit false values.

Use ?? instead of || for booleans coming from external data.

-        isWaitingForUserInteraction: windowData.isWaitingForUserInteraction || false,
-        isProcessingQueuedMessages: windowData.isProcessingQueuedMessages || false,
+        isWaitingForUserInteraction: windowData.isWaitingForUserInteraction ?? false,
+        isProcessingQueuedMessages: windowData.isProcessingQueuedMessages ?? false,
@@
-        isWaitingForUserInteraction: event.data.isWaitingForUserInteraction || false,
-        isProcessingQueuedMessages: event.data.isProcessingQueuedMessages || false,
+        isWaitingForUserInteraction: event.data.isWaitingForUserInteraction ?? false,
+        isProcessingQueuedMessages: event.data.isProcessingQueuedMessages ?? false,

Also applies to: 86-87

---

71-97: Don’t re-register window message listener on state changes.

The effect re-runs on chat length/waiting flag changes, causing unnecessary add/remove. Register once on mount.

-  useEffect(() => {
+  useEffect(() => {
     const handleMessage = (event: MessageEvent<ExtensionData>) => {
@@
     return () => {
       window.removeEventListener("message", handleMessage);
     };
-  }, [state.chatMessages.length, state.isWaitingForUserInteraction]);
+  }, []); // register once

If you need latest state in the handler, derive it from event.data (as you already do), so a stable listener is fine.

vscode/core/src/solutionWorkflowOrchestrator.ts (4)

20-22: Type the workflow field.

Avoid any; use KaiInteractiveWorkflow for safer refactoring.

-  private workflow: any;
+  private workflow!: import("@editor-extensions/agentic").KaiInteractiveWorkflow;

---

288-301: Brittle error detection by string match.

Checking for “Invalid string length” is fragile. Prefer error.name/type (RangeError) and/or a predicate helper.

-    const isStringLengthError = errorMessage.includes("Invalid string length");
+    const isStringLengthError =
+      (err instanceof RangeError && err.message.includes("Invalid string length")) ||
+      errorMessage.includes("Invalid string length"); // fallback

---

230-235: Hardcoded programming language.

If available in incidents or settings, derive programmingLanguage instead of hardcoding "Java".

const programmingLanguage =
  this.incidents[0]?.language ??
  this.state.profiles?.find(p => p.name === profileName)?.language ??
  "Java";

---

441-450: Return type for validation could be discriminated for clarity.

Using strings to branch on UI (warning vs error) is brittle. Consider {valid:false, code:'already-fetching'|'genai-disabled'|...}.

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Learnt from: pranavgaikwad
PR: konveyor/editor-extensions#874
File: vscode/src/utilities/ModifiedFiles/handleFileResponse.ts:238-248
Timestamp: 2025-09-30T13:30:21.839Z
Learning: In the vscode extension's ModifiedFile handling (vscode/src/utilities/ModifiedFiles/handleFileResponse.ts), not all ModifiedFile messages have a userInteraction field associated with them. The hasUserInteraction check is used to conditionally add the response field only when there is an actual userInteraction, because only those cases have a pending workflow promise that needs to be resolved.

Learnt from: djzager
PR: konveyor/editor-extensions#678
File: vscode/src/commands.ts:135-139
Timestamp: 2025-08-12T02:13:55.897Z
Learning: In vscode/src/commands.ts, the solutionState is conditionally reset to "none" after successful getSolution completion, but only when !state.isWaitingForUserInteraction. This prevents permanent blocking of future getSolution calls while still maintaining proper concurrency control during active workflows.